Data Types

Overview#

Data types play an important part in a system. They’re used to encapsulate and transmit information. In particular, when we discuss software systems, it’s important to make sure that types shared by different systems are known to all of those systems. The knowledge of data types and formats is, in fact, a form of coupling.

Think about the many languages of the world. If we have to talk to an audience, we have to use a language that they understand. This couples us with our audience. This course is in English, which means we’re coupled with English-speaking readers. If all English speakers in the world suddenly decide that they don’t want to use English anymore and replace it with Italian, we then need to redesign this course from scratch (though, admittedly, with less effort).

Similarly, when we consider a software system in this way, we need to understand which parts define the type and format (the language) of our data. It’s also important to ensure that the resulting dependencies don’t get in the way of implementation. In the lesson “The Data Flow,” we learned that there are components in the system that are of primary importance and represent the core of the system (use cases). There are also some other components that are less centralized, which we refer to as implementation details.

Even though these implementation details are less centralized to our system, it doesn’t mean that they’re not important or that they’re too trivial to be implemented. It simply means that if we replace them with different implementations, it doesn’t affect the core of the system (business logic).

In short, we can say that there’s a hierarchy of components that result from the dependencies between them. Some components are defined at the very beginning of the design and are not dependent on any other component. Others may be defined later and can be dependent on previously defined components. When data types are involved, the dependencies that result can’t break this hierarchy because this reintroduces coupling between components, something we want to avoid.

The Shop Example#

Let’s go back to the initial example of a shop that buys items from wholesale, displays them on its shelves, and sells them to customers. There is a clear dependency between two components here: the component called “shop” depends on the component called “wholesale”, as the data (items) flow from the latter to the former. The size of the shelves in the shop, in turn, depends on the size of the items (types), which is defined by the wholesale and is dependent on the dependency we already established.

If the size of the items were to be defined by the shop, suddenly there would be another dependency opposing the one we already established, making the wholesale depend on the shop. In software systems, this shouldn’t be considered a circular dependency because the first one is a conceptual dependency while the second one happens at the language level at compile time. At any rate, having two opposite dependencies is confusing and makes it hard to replace peripheral components such as the shop.